1. Field of the Invention
The present invention generally relates to networked computer systems, and more particularly, to methods and systems for executing individual design automation tasks without interference from other similar tasks being executed on the same computer or network of computers.
2. Description of the Related Art
An on-demand environment can be described as one or more discrete computers, each possessing one or more processing units (e.g., CPUs) joined together to from a computer network. The on-demand aspect is embodied by management software that receives processing requests and then applies the most appropriate resources to processing requests when available. In addition, the management software may change the resources allocated to a running process, to both increase and decrease the resources allocated to a running process, depending on a variety of factors. One embodiment of a management software product is IBM's Load Leveler® application. The management software is aware of the resources that are currently being used to satisfy processing requests as well as the resources that remain available, and is further configured to detect when computing resources are added to or removed from the on-demand environment.
The on-demand environment (also referred to as a computing grid) includes an arbitrary number of, possibly heterogeneous, computer systems. Large computing grids are capable of harnessing tremendous computing power. It has become useful for the owners of such large computing grids to accept job processing requests from unrelated entities. For example, design automation tasks such as high-level synthesis, logic synthesis, static timing analysis, placement, and physical synthesis (among others) are strong candidates for an on-demand, grid-based solution. Typically, these tasks may be characterized as being long running processes that can take multiple hours or even days to complete, and often require very large amounts of computational resources. Additionally, because the tasks require a limited amount of data and execution logic, the tasks may be transmitted over a network in a reasonable time. Because the constraining aspect is processing time, the more computational “horsepower” available to process a design automation task, the faster a job may be completed. Accordingly, maximizing the utilization of computing resources is an important goal for an on-demand grid services provider.
A grid services provider may process design automation tasks on a first come first served basis or on a reservation basis. Problems arise, however, when processing requests from different entities are allowed access to the same computing grid. First, security concerns arise where the processing request from one entity might be allowed to snoop on the activity of other tasks being processed by the computing grid or on the grid itself. Second, aside from these security concerns, design automation tasks may be very complex, and if not properly constructed, may operate incorrectly, interfering with other processes or “crashing” portions of the grid.
One common solution to this problem is to partition grid resources to a task in advance. When a new task arrives at the grid (e.g., is transmitted over a network to a “drop box” server), an estimate of resources required to complete the task is made, and a subset of grid resources may be partitioned to the new task, giving the task its own closed environment in which to execute. Doing so segregates tasks from one another, thereby preventing one task from eavesdropping on another. Further, an errant task is prevented from disrupting no more than the grid resources allocated to it due to a “crash” or other exception event.
This approach, however, may leave grid resources unused, even when available. For example, consider a grid with 32 memory units available to store data. If one process is partitioned 18 units, but only uses 12, then a second task requiring 16 units will have to wait until the first process completed, despite that collectively, only 28 units are required to complete both tasks simultaneously. Also, once a job completes, the resources partitioned to it may have to be “scrubbed.” For example, hard drives may have to be erased, and operating systems re-installed to ensure that one task did not bring in (or itself comprise) a “Trojan horse” that may either eavesdrop on subsequent activity or damage grid resources. Doing so, however, takes time and reduces the resources that are available to other tasks, which may itself cause other tasks to take longer to complete, further reducing the utilization of a computing grid.
Another approach is for the grid provider to also provide a number of pre-defined tasks that may be carried out by the computing grid. This way, parties only need to submit data components to the grid provider. This approach, however, prevents entities from developing their own design automation programs. Thus, a grid provider may not be able to provide all the services needed for a particular entity. Further, it may prevent one party from employing requisite proprietary processing techniques.
Accordingly, there remains a need for a grid services provider to maximize the availability of a computing grid while simultaneously protecting the security of unrelated processing tasks. In particular, concurrently executing design automation tasks should execute without interference from others, and conversely, should be prevented from accessing or eavesdropping on others. Additionally, the computing grid itself should be protected from intentional or unintentional harm that may be caused by processing a design automation task.